Fault-tolerant communications in routed networks

ABSTRACT

A method for providing fault-tolerant network communications between a plurality of nodes for an application, including providing a plurality of initial communications pathways over a plurality of networks coupled between the plurality of nodes, receiving a data packet on a sending node from the application, the sending node being one of the plurality of nodes, the data packet being addressed by the application to an address on one of the plurality of nodes, and selecting a first selected pathway for the data packet from among the plurality of initial communications pathways where the first selected pathway is a preferred pathway.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of and claims benefit from U.S.patent application Ser. No. 12/884,101 that was filed on Sep. 16, 2010and that is a Continuation of and claims benefit from U.S. patentapplication Ser. No. 11/275,185 that was filed on Dec. 16, 2005 and thatclaims priority from U.S. Provisional Patent Application No. 60/716,122and was filed on Sep. 12, 2005, each of which are incorporated herein byreference in its entirety.

BACKGROUND

In a computer networking environment, multiple nodes may communicatewith each other over a network. Should the network experience a failure,communication between the nodes may be disrupted.

SUMMARY

The following presents a simplified summary of the disclosure in orderto provide a basic understanding to the reader. This summary is not anextensive overview of the disclosure and it does not identify key orcritical elements of the invention or delineate the scope of theinvention. Its sole purpose is to present some concepts disclosed hereinin a simplified form as a prelude to the more detailed description thatis presented later.

The following examples provide computer network communicationfault-tolerance via unique network stack architectures requiring minimalconsideration by application software operating on networked nodes.

Many of the attendant features will be more readily appreciated as theybecome better understood by reference to the following detaileddescription considered in connection with the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the followingdetailed description read in light of the accompanying drawings,wherein:

FIG. 1 is block diagram showing an example network stack architecture.

FIG. 2 is a block diagram showing a networked computing environmentincluding two example nodes coupled via two networks.

FIG. 3 is a block diagram showing an example fault-tolerantcommunications driver, NETFT.

FIG. 4 is a block diagram showing an example fault-tolerantcommunications architecture including NETFT and an application.

FIG. 5 is a flow diagram showing data flowing through a fault-tolerantcommunications environment including a source node and a destinationnode coupled via Path A over network 1 and Path B over network 2.

FIG. 6 is a flow diagram showing data flowing through the fault-tolerantcommunications environment shown in FIG. 5 with the addition of severalpossible communications failures.

FIG. 7 is a block diagram showing and another example of afault-tolerant communications driver, NETFT.

FIG. 8 is a block diagram showing an example fault-tolerantcommunications architecture including NETFT and an application.

FIG. 9 is a flow diagram showing data flowing through a fault-tolerantcommunications environment including a source node and a destinationnode coupled via Path A over network 1 and Path B over network 2.

FIG. 10 is a flow diagram showing data flowing through thefault-tolerant communications environment shown in FIG. 9 with theaddition of several possible communications failures.

FIG. 11 is a block diagram showing an example computing environment inwhich the technology described above may be implemented.

Like reference numerals are used to designate like parts in theaccompanying drawings.

DETAILED DESCRIPTION

The detailed description provided below in connection with the appendeddrawings is intended as a description of the present examples and is notintended to represent the only forms in which the present examples maybe constructed or utilized. The description sets forth the functions ofthe examples and the sequence of steps for constructing and operatingthe examples. However, the same or equivalent functions and sequencesmay be accomplished by different examples.

Although the present examples are described and illustrated herein asbeing implemented in a computing and networking system, the systemdescribed is provided as an example and not a limitation. As thoseskilled in the art will appreciate, the present examples are suitablefor application in a variety of different types of computing andnetworking systems.

FIG. 1 is block diagram showing an example network stack architecture100. A network stack (“stack”) generally couples with softwareapplications via network stack interfaces and/or other interfaces toprovide network communications functionality to applications. Anapplication is typically said to be at (or coupled to) the “top” of thestack. A network is typically said to be at (or coupled to) the “bottom”of the stack. Various elements of a network stack may be referred to asat or near the top or bottom of the stack, or higher or lower in thestack relative to each other. For example, in FIG. 1, protocol driver130 is higher in the stack than NIC 180 which is shown at the bottom ofthe stack in this particular figure. Various depictions of a networkstack may or may not include some stack elements, or may group, order orname the elements in various ways, depending on the purpose or focus ofthe depiction, as understood by those skilled in the art.

The term “driver” as used herein refers to a control program or the likethat enables a node to operate with a particular device, such as aprinter, network interface card, or other computer subsystem, or tooperate with one or more programs such as network stacks, protocoldrivers, and/or other computer software or firmware or the like. Forexample, a protocol driver typically operates with a network stack.

An application may pass a packet of data to a stack destined for anapplication operating on another node. In this case, the data is said toflow “down” the stack and is sent out over a network. Data received by anode is said to flow “up” the stack until it reaches the destinedapplication. Such networking systems are well known to those skilled inthe art.

In one example a stack is based on the Network Driver InterfaceSpecification (“NDIS”) which defines a standard application programminginterface (“API”) for network interface cards (“NICs”), such as NIC 180,and abstracts the network hardware from network drivers. NDIS alsospecifies a standard interface between layered network drivers, therebyabstracting lower-level drivers that manage hardware, such as a miniportdriver, from upper-level drivers, such as protocol drivers. MultipleNDIS-conforming protocol drivers may co-exist on a single node. Also, ifa node includes multiple NICs, perhaps because it is connected to morethan one network, NDIS routes network traffic to the appropriate NIC viaits associated driver as indicated by the traffic. An illustration ofNDIS is shown in FIG. 1. Other networking stack standards, technologiesand/or architectures, such as the Open Data-Link Interface (“ODI”), theData Link Provider Interface (“DLPI”), the Uniform Driver Interface(“UDI”), or other technologies, may be used with the following examplesas well with appropriate modifications, as would be understood by thoseskilled in the art. As a matter of convenience, NDIS and NDISterminology is used with examples throughout this description, but otherstandards, technologies and/or architectures may be used in all of theseexamples with appropriate modifications, unless otherwise noted.

As shown in FIG. 1, coupled to NIC 180 via NDIS 120 is miniport driver160. A miniport driver typically interacts with NDIS via an NDISminiport interface 162. The miniport driver 160 may be associated withNIC 180 and may manage its operations, including sending and receivingdata through the NIC. The miniport driver 150 typically interfaces withhigher-level drivers, such as intermediate driver 140 and protocoldriver 130. A miniport driver is considered a NIC driver. NIC min portsgenerally perform those hardware-specific operations needed to manage aparticular NIC with common or NIC-independent functionality provided byNDIS. A node may include multiple NICs with each NIC generally having anassociated NIC driver. Some examples in this description describe theuse of miniport drivers but as will be understood by those skilled inthe art, any type of NIC driver or the like may be used in theseexamples, unless otherwise noted.

Protocol or transport driver 130 couples to NDIS 120 via an NDISprotocol interface 134. Protocol drivers or transport protocol driversgenerally provide the functionality to create, send and receive packetsof data that are sent from one node to another through the network stackand over a network. As known to those skilled in the art, a commonreliable or guaranteed delivery transport protocol may be TCP/IP(Transmission Control Protocol/Internet Protocol). UDP (User DatagramProtocol) over IP may be a common unreliable or non-guaranteed deliveryprotocol. TCP, UDP and/or other protocols, such as IPX/SPX (InternetPacket Exchange/Sequenced Packet Exchange), may be used with thefollowing examples unless otherwise noted.

NDIS intermediate (“IM”) drivers 140 are shown between protocol drivers130 and NDIS NIC min ports 160 in FIG. 1. To protocol drivers IM driversappear to be NDIS miniports while to NIC drivers they look like protocoldrivers. Data packets flowing up or down the network stack pass throughthe IM driver 140 which may ignore, inspect, filter, forward, redirectand/or modify the data packets. An intermediate driver 140 may also beknown as a filter driver.

FIG. 2 is a block diagram showing a networked computing environment 200including two example nodes 210 and 260 coupled via two networks 202 and282. Nodes 210 and 260 may each be personal computers (“PCs”), clientcomputers, servers, hosts, laptops, portable devices, consumerelectronic devices, or any of various other types of computing orprocessing devices, machines or systems. One non-limiting example of atype of computing system is described in detail below with respect toFIG. 11. Circles 212, 214, 262, and 264 represent NICs associated withtheir respective nodes. One non-limiting example of a type of NIC isfurther described below with respect to FIG. 11 as network adapter 1113.

As used herein, the term node refers to any computing system, device, orprocess that is uniquely addressable, or otherwise uniquelyidentifiable, in a network (e.g., network 202) and that is operable tocommunicate with other nodes in the network. For example, and withoutlimitation, a node may be a personal computer, a server computer, ahand-held or laptop device, a tablet device, a multiprocessor system, amicroprocessor-based system, a set top box, a consumer electronicdevice, a network PC, a minicomputer, a mainframe computer, or the like.A non-limiting example of a node 210, in the form of a computing system,is set forth below with respect to FIG. 11.

Networks 202 and 282 may be the same network, may exist on the same ordifferent subnets, may be logically or physically coupled or isolatedfrom each other, may use similar or different networking technologies,etc. In particular, networks 202 and 282 may be routed networks, thatis, networks including routers that forward routable protocol packets.Routable protocols are typically considered communications protocolsused to route data from one network to another. An example of a routableprotocol is TCP/IP. Sending a data packet in a routable fashion impliesusing a routable transport protocol to format and/or send the datapacket. Those skilled in the art will be familiar with routableprotocols and routing network topologies, systems and architectures.

In one example, networks 202 and 282 may be independent of each othersuch that if there is a problem or failure with one network it isunlikely to affect the operational status of the other. In otherexamples, three or more networks may be used. In examples where greaterdegrees of fault-tolerance are desired a larger number of networks alongwith the associated connectivity of nodes to those networks, including asimilar number of NICs installed on a node, may be employed.

NEC 212, associated with node 210, is shown with an example address of172.56.48.37 and is coupled to network 1 202. NIC 214, also associatedwith node 210, is shown with an example address of 197.71.48.38 and iscoupled to network 2 282. NEC 262, associated with node 260, is shownwith an example address of 172.56.48.38 and is also coupled to network 1202. NEC 264, also associated with node 260, is shown with an exampleaddress of 197.71.48.39 and is also coupled to network 2 282. Theseaddresses may, in practice, be IPv4 or IPv6 addresses or the like, orany other type of network address typically related to the protocolbeing used.

Each node may include one or more NICs. Arrows 201 and 203, also shownin FIG. 11 as arrow 1114, represent a first communications route orpathway (“Path A”) over network 1 202 between nodes 210 and 260. Arrows281 and 283 represent a second communications route or pathway (“PathB”) over network 2 282 between nodes 210 and 260. In practice, there maybe one or more pathways over one or more networks between the two ormore nodes in environment 200. The term “pathway” as used herein isdefined as a communications route, or communications link, between nodesin a network. Such a route or link may be dynamic in that the exactroute between nodes may change over time.

Blocks 216 and 266 represent an application and a network stack,including a fault-tolerant communications (“FT”) driver, provided oneach of nodes 210 and 260. The FT driver of block 216 is shown with anexample address of 10.0.0.1 and the FT driver of block 266 is shown withan example address of 10.0.0.2. These addresses are typically consideredvirtual addresses. These addresses may be IPv4 or IPv6 addresses or thelike, or any other type of network or communications address. FT driversmay or may not have virtual addresses as shown in the various examplesbelow.

A fault-tolerant network stack is a network stack including an FTdriver, such as NETFT described below in connection with FIG. 3, or thelike. An FT driver, such as NETFT, operating in combination with anetwork stack typically allows nodes to communicate with each other viaone or more communications paths, such as Path A and Path B, over one ormore networks. Should any of these communications paths fail, the nodesmay continue communicating given at least one operational pathway. Sucha pathway failure may result from failure of a NIC or failure of anyelement of a pathway, including connections, cabling or othercommunications media (including radio frequency (“RF”) or infrared(“IR”) and the like), routers, hubs, switches, firewalls, InternetService Providers (“ISPs”), power failure to any node, device or systemof the network, or the like.

In one example, a communications failure may result in a plug-and-play(“PnP”) event. A PnP event may indicate the removal of a NIC from itsnode or to a media sense change. A media sense disconnect, for example,typically results from a failure that causes the NIC to lose the signalor carrier on the network media, such as a network cable, RF or IR linkor the like. A media sense disconnect may be caused by disconnecting thenetwork cable or carrier from the NIC or powering off the other end ofthe cable (a hub or switch, for example). A media sense connect istypically the opposite, such as reconnecting the cable, re-powering onthe hub or switch or the like. These types of events, also known asconnectivity events, are generally local events in that they occur on orare proximate to the node itself. Such local connectivity eventstypically result in an event indication, such as a PnP event or thelike, on a node.

In another example, a communications failure may be detected by usingheartbeat packets sent between nodes. Failure of such a heartbeat packetmay indicate failure of a pathway between nodes. Heartbeat packets tendto be marked such that the FT driver can detect them upon receipt andremove them for the packet flow being passed up the network stack. Inone example, heartbeat packets may be implemented using route controlprotocol (“RCP”) by forming RCP packets. Such heartbeat packets may beused to validate the end-to-end operational status of a pathway. Thatis, by sending a heartbeat packet from node 210 over Path A to node 260and by node 210 receiving a reply to the sent heartbeat packet from node260, it is generally considered that Path A is end-to-end operational.Should the heartbeat fail (no heartbeat reply received in response tothe heartbeat sent), such a failure may indicate that Path A is notoperational, perhaps due to fail of some element of network 1 202 suchas a router, switch, connect on, or the like, or due to the target nodeitself failing. In particular, node 210 may have an operational NIC 212and valid media sense, indicating that it is properly connected to thenetwork, but may still detect a heartbeat failure due to some network orsystem failure down the line.

FIG. 3 is a block diagram showing an example fault-tolerantcommunications driver, NETFT 300. NETFT 300 may be implemented as anNDIS miniport driver (FIG. 1, 160) for use with an NDIS network stackand for providing network communications between nodes tolerant ofpathway failures. That is, communications between two or more nodes maycontinue when each is using a NETFT despite failure of any component inthe pathway as long as at least one pathway remains operational.

In one example, implementation of the FT driver as an NDIS miniportdriver provides at least two benefits. First, because such an FT drivergenerally sits below any protocol drivers in the stack, protocolreliability tends to be provided by any higher-level reliable protocoldriver which is generally unaffected by the addition of link-levelfault-tolerance provided by an FT driver. For example, when using an FTdriver in combination with a protocol driver such as a TCP/IP driver,the FT driver will typically detect failed pathways and route datapackets over end-to-end operational pathways independent of any protocoldriver. Should any packet loss occur due to switching pathways, theTCP/IP protocol driver, which generally sits above the FT driver in thestack, tends to detect such losses and perform any retry or resendoperations to ensure that the reliable protocol succeeds in packetdelivery.

A second benefit of placing the FT driver below the protocol driver inthe stack is that typically no degradation of the routability of theprotocol is introduced. When so configured, any tunneling operation thatan FT driver performs on a data packet may employ a routable protocol,such as TCP or UDP, thus ensuring that such data is routable, inaddition to being link-level fault tolerant. To “routeably tunnel” adata packet is to tunnel a data packet using a routable protocol.

NETFT, as a part of a network stack, generally couples to a softwareapplication via NDIS or other network stack interfaces. Such a couplinggenerally enables applications to send and receive data packets overnetworks coupled to the bottom of the stack. In one example,applications tend to use a virtual address as the source address fortheir data packets, this virtual address being known to NETFT and mappedand communicated to other nodes on the network as described below. Asshown in FIG. 3, NETFT includes a miniport adapter 302 (also known as aprocessing element) a routing database 304, and one or more routemonitor adapters 306 and tunnel adapters 308.

Tunnel adapter 308 typically represents one NIC on the local node (or,in some instances, a virtual NIC) and maintains a socket used to tunnelpackets to NETFT on the target node. There is typically one tunneladapter 308 associated with each NIC on the local node with each NICbeing coupled to a network providing a pathway to another node. Eachnetwork may or may not be isolated from any other network. A tunneladapter 308 is typically associated with a tunneling protocol driver andtunnels data packets through a tunneling protocol to and from itsassociated NIC via NDIS interfaces. One example of a tunneling protocolis UDP. Alternatively, other protocols, such as TCP, IPX, or SPX, may beused for tunneling. A tunnel adapter 308 may become inactive should theassociated NIC or media connection become inactive.

A routing database 304, as implemented in NETFT, is typically a simpledata structure, that may be located in system memory, that includesentries mapping a virtual address for one or more pathways to a similarNETFT on another node. In one example, mappings are represented by routemonitor adapters such as route monitor adapter 306 which are typicallyassociated with a tunnel adapter such as tunnel adapter 308. Generally arouting database such as routing database 304 will include one set ofroute adapters for each tunnel adapter, each route adapter beingassociated with a different target node reachable over the pathwayassociated with the tunnel adapter. When using TCP/IP, for example, thedatabase may map a destination virtual address to a physical address ofa specific remote node.

A routing database 304 may also include priority information for eachpathway. Such priority information may be used to indicate a preferredor primary pathway to another node and/or may include information aboutpathway speed or other characteristics. A preferred pathway is thepathway calculated by NETFT to be used over other possible pathways,when possible, based on priority information and/or pathway status.Priority information may alternatively indicate a round-robin loadbalancing algorithm for making use of multiple pathways to a target nodeto load-balance traffic over the pathways, or enable some other pathwayprioritization scheme.

An example routing table database 304 mapping table is shown in Table 1.

TABLE 1 Destination Address Type Address Priority Virtual 10.0.0.2 —Physical: Path A 172.56.48.38 1 Physical: Path B 197.71.48.39 2

Referring to table 1 and FIG. 2, table 1 shows an example mapping tableas might be used by NETFT operating on node 216. Table 1 shows virtualdestination address 10.0.0.2, the virtual address as shown for node 266,mapped to physical address 172.56.48.38 associated with Path A to node266 and physical address 197.71.48.39 associated with Path B to node266. Path A is shown with first priority and Path B with secondpriority. Table 1 is provided as an example and is not intended to belimiting.

When sending data from node 216 to node 266, such a mapping table istypically used to tunnel a packet destined to virtual destinationaddress 10.0.0.2 by forwarding the packet via a tunneling protocol, suchas UDP, to physical destination address 72.56.48.38, thus tunneling thepacket from node 216 over Path A to node 266. One such mapping table maybe created in the routing database (FIG. 3, 304) for each set ofpathways established between two nodes. Such a mapping table may beimplemented in various forms, use various priority schemes and/or storeother information including pathway operational status. The mappingtable structure, number of pathways, address formats, etc. shown inTable 1 are provided as examples and are not intended to be limiting.

The local node virtual address, remote node virtual addresses, andpriority and other pathway information are typically provided to nodesby an out-of-band mechanism and passed to NETFT via its NDIS interfaces.This out-of-band mechanism may be as simple as a systems administratorusing a management application to specify the information, or it may bean automated system or the like. Such out-of-band mechanisms are wellknown to those skilled in the art.

As shown in FIG. 3, miniport adapter 302 (also known as the processingelement of the driver) typically parses a data packet flowing down thenetwork stack, examines the destination virtual address of the packetand uses information from the routing database 304 to determine whichtunnel adapter 308 to tunnel the data packet through. Incoming packets,or data packets flowing up the stack, are forwarded up the stack towardtheir destination virtual address, the tunneling protocol havingpreviously removed the tunneling packet headers. In particular, thetunnel adapter 308 inspects incoming packets and forwards heartbeatpackets to a route monitor adapter 306 and forwards other packets up thestack via a miniport adapter 302. Aspects of tunneling data packetsusing a tunneling protocol and how protocol headers are added andremoved by protocol drivers is well known to those skilled in the art.

Route monitor adapter 306 typically represents a remote node accessibleover a specific pathway identified by an associated tunnel adapter. Theroute monitor adapter 306 will typically provide a physical address forthe remote node, the physical address also corresponding to a specificpathway to the remote node. This physical address is typically used formappings in a routine database 304. There is typically one route monitoradapter for each distinct pathway to a remote node, each route monitoradapter being associated with a tunnel adapter representing a pathway.In one example, referring back to FIG. 2, node 210 is shown coupled tonode 260 over two pathways, one through network 1 202 (“Path A”) and theother through network 2 282 (“Path B”). NETFT operating on node 210 mayinclude a first route monitor adapter (“RMA-A”) providing remote node260's physical address 172.56.48.38 associated with its NIC 262. RMA-Amay be associated with a first tunnel adapter (“TA-A”) on node 210 whichmay be associated with Path A. NETFT on node 210 may also include asecond route monitor adapter (“RMA-B”) providing remote node 260'ssecond physical address 197.71.48.39 associated with its NIC 264. RMA-Bmay be associated with a second tunnel adapter (“TA-B”) on node 210which may be associated with Path B.

Referring to FIG. 3, route monitor adapter 306 typically monitors thehealth of a pathway to a remote node and indicates a failed ornon-operational pathway in the routing database 304. Monitoringtypically includes receiving any event indications and/or noting anyheartbeat failures and updating the database 304 accordingly. In oneexample, an event indicating the failure of a NIC or media connectionmay result in the disabling of the tunnel adapter 308. In anotherexample, a heartbeat failure may result in the disabling of the routemonitor adapter 306 associated with the specific remote node for whichthe heartbeat failed.

FIG. 4 is a block diagram showing an example fault-tolerantcommunications architecture 216 including NETFT 300 and an application402. In this example, the application 402 sends data packets to NETFT300 via the stack using a virtual source address 217 and a virtualdestination address representing the destination node. Such out-goingdata packets flow via path 480 from the application and through thenetwork stack to the driver 300. The driver 300 typically determineswhich of the possible pathways each packet should take, generally usingpriority information and pathway operational status information storedin the routing database, and tunnels the packet to the target node overthe selected pathway using the appropriate physical source address 422or 424.

Application 402 may send a data packet through NETFT 300 via the TCPprotocol, as shown in FIG. 4. Alternatively UDP or any other protocolmay be used. Also, as shown, NETFT 300 may use the UDP protocol totunnel packets to the target node. Alternatively, TCP or any otherprotocol may be used for tunneling. Further, alternate examples may notmake use of miniport adapters or NDIS drivers but may use othermechanisms or architectures to perform similar functions. Finally, thevarious elements of the network stack and the like may operate in eithera User Mode or a Kernel Mode, either as shown or otherwise, or onsystems with or without equivalent modes of operation.

FIG. 5 is a flow diagram showing data flowing through a fault-tolerantcommunications environment 500 including a source node 216 and adestination node 266 coupled via Path A over network 1 202 and Path 6over network 2 282. In this example environment 500, data is shown beingsent from the application operating on node 216 to the applicationlistening on the destination virtual address on node 266. The datapackets flow down the network stack operating on node 216 using the TCPprotocol into NETFT as shown by path 501. Assuming, as shown, that PathA is the selected pathway, NETFT maps the data packets from the sourcevirtual address being used by the application to Path A and tunnels thedata through the UDP protocol using the Path A physical destinationaddress for target node 266, out NIC 1 of node 216 as further shown bypath 501 and onto network 1 202 via link 201. The data then flowsthrough network 1 202, over link 203 and to node 266, flowing up thenetwork stack operating on node 266 as shown by path 503. The data thenflows through the UDP protocol driver, the same protocol that was usedon the sending side as the tunneling protocol, where the UDP protocolheaders are stripped off the data packets which are then passed intoNETFT operating on node 266. NETFT then forwards the data packets up thestack to the application which is listening on the destination virtualaddress. Responses tend to flow in the reverse order.

FIG. 6 is a flow diagram showing data flowing through the fault-tolerantcommunications environment 500 shown in FIG. 5 with the addition ofseveral possible communications failures 610, 612, 620, 622, and 630.Other communications failures are also possible. Failure 610 indicates afailure of NIC 1 operating on the sending node 216. Such a failure mayoccur should NIC 1 be removed from the node, should the driver of NIC 1fail, should NIC 1 itself fail, or the like. The failure may be detectedby NETFT via an event indication, such as a PnP event or the like,and/or a heartbeat failure. In such a situation Path A is typicallyconsidered to have failed and NETFT will select an alternateend-to-end-operational pathway. An end-to-end operational pathway istypically a pathway that can successfully deliver data from the sourcenode and application all the way to the destination node andapplication.

Failure 620 indicates a failure of the network media coupling with NIC1of node 216. This failure may be due to a cable being disconnected fromNIC 1, from the cable becoming disconnected from some device of network1 202, from the device the cable is connected to on the network sidebeing powered down or failing, or the like. This type of failure mayalso be detected by NETFT via an event indication, such as a PnP eventor the like, and/or a heartbeat failure and an alternate pathwayselected.

Failure 630 indicates a failure of some type within network 202resulting in data packets failing to reach destination node 266. In thisfailure case, sending node 216 may still be coupled to network 202 witha proper media sense indication, yet Path A has become disrupted furtherdown the network. Given such a failure, NETFT operating on sending node216 may not detect the failure via an event indication if localindications show connectivity to the network 202 as good, but may detectthe failure via Path A heartbeat failure.

Failure 622 of link 203 and failure 612 of NIC 1 operating on receivingnode 266 tend to be similar to the corresponding failures shown for node216. But these failures, not being local to node 216 may not be detectedvia event indications but may be detected via heartbeat failure.

Any of these failures, and other failures, may be detected by NETFToperating on node 216 and result in it selecting an alternate end-to-endoperational pathway, such as Path B over network 2 282. In this example,as shown in FIG. 6, NETFT tunnels data down alternate path 681 and overnetwork 2 282 to receiving node 266. Should the failure condition becorrected and end-to-end operational status restored on Path A, NETFToperating on sending node 216 may detect the recovery and again make useof Path A. Further, any responses from node 266 back to node 216 may betunneled in a similar fault-tolerant fashion by NETFT.

FIG. 7 is a block diagram showing and another example of afault-tolerant communications driver. NETFT 700. This example is similarto the example shown in FIG. 3 but includes variations as describedbelow. In this example, a software application may not need to usevirtual addresses. Instead, an application may use a physicaldestination address to address data packets to the target node.

Protocol adapter 710 generally couples to miniport adapter 702 (alsoknown as the processing element of the driver) and to a NIC miniportadapter (not shown). There is typically one protocol adapter for eachNIC installed on the node, each protocol adapter being associated with aNIC via its NIC adapter. As each protocol adapter is associated with aNIC, it is also associated with the pathway coupled to the NIC. Theprotocol adapter 710 is operable to accept data packets from anapplication via the processing element 702 and pass the data packets tothe associated NIC without the need for tunneling.

Processing element 702 typically parses a data packet flowing down thenetwork stack, examines the physical destination address of the packetand uses information from the routing database 704 to determine if thepacket can be forwarded over a protocol adapter 710 or needs to betunneled over a tunnel adapter 308 to the target node. Generally, if thepathway indicated by the physical destination address is end-to-endoperational, the data packet will be sent over that pathway. Otherwiseand alternate pathway may be selected over which the packet may betunneled.

In this example the routing database 704 maintains mappings of physicaldestination addresses and pathways, along with priority and otherinformation as described above. An example routing database 704 mappingtable is shown in Table 2.

TABLE 2 Destination Address Type Address Priority Physical: Path A172.56.48.38 1 Physical: Path B 197.71.48.39 2

Referring to Table 2 and FIG. 2, Table 2 shows an example mapping tableas might be used by NETFT operating on node 216. Table 2 shows a mappingincluding physical destination address 172.56.48.38 associated with PathA to node 266 and the physical destination address 197.71.48.39associated with Path B to node 266. Path A is shown with first priorityand Path B with second priority.

When sending data from node 216 to node 266, such a mapping table istypically used in forwarding (or tunneling if needed) a data packetbeing sent to physical destination address 172.56.48.38 of node 266. Ifthe pathway associated with the original destination address isoperational, the data packet tends to be forwarded to the destinationnode without tunneling. If that pathway in not available, then the datapacket is sent over the alternate pathway to physical destinationaddress 197.71.48.39 of node 266 via tunneling. Other aspects of NETFT700 are generally similar to those of NETFT as described for FIG. 3.

FIG. 8 is a block diagram showing an example fault-tolerantcommunications architecture 216 including NETFT 700 and an application402. In this example, application 402 sends data packets to NETFT 700via the stack using a physical source address and a physical destinationaddress 801 representing the destination node. Such out-going datapackets flow via path 880 from the application and through the networkstack to the driver 700. The driver 700 typically determines which ofthe possible pathways each packet should take, generally using priorityinformation and pathway operational status information stored in therouting database, and either forwards the packet to the target node overpathway indicated by the original physical destination address or, ifthat pathway is not end-to-end operation, tunnels the packet over analternate pathway as indicated in this example by route 882 and NIC 2892.

Application 402 may send a data packet through NETFT 700 via the TCPprotocol, as shown in FIG. 8. Alternatively UDP or any other protocolmay be used. Also, as shown, NETFT 700 may use the UDP protocol totunnel packets to the target node. Alternatively, TCP or any otherprotocol may be used for tunneling. Further, other examples may not makeuse of NDIS drivers but may use other mechanisms or architectures toperform similar functions. Finally, the various elements of the networkstack and the like may operate in either a User Mode or a Kernel Mode,either as shown or otherwise, or on systems with or without equivalentmodes of operation.

FIG. 9 is a flow diagram showing data flowing through a fault-tolerantcommunications environment 900 including a source node 816 and adestination node 966 coupled via Path A over network 1 202 and Path Bover network 2 282. In this example environment 900, data is shown beingsent from the application operating on node 216 to the applicationlistening on the destination physical address on node 266. The datapackets flow down the network stack operating on node 216 using the TCPprotocol into NETFT as shown by path 901. Assuming, as shown, that PathA is the selected pathway, NETFT forwards the data packets using thephysical destination address provided by the application via NIC 1 ofnode 216 over Path A and network 1 202 via link 201. The data then flowsthrough network 1 202, over link 203 and to node 966, flowing up thenetwork stack operating on node 966 as shown by path 903. The data thenflows through NETFT and the protocol driver (a protocol driver for thesame protocol that was used on the sending side as the sending protocol)and up to the application. Responses tend to flow in the reverse order.

FIG. 10 is a flow diagram showing data flowing through thefault-tolerant communications environment 900 shown in FIG. 9 with theaddition of several possible communications failures 1010, 1012, 1020,1022, and 1030. Other communications failures are also possible. Failure1010 indicates a failure of NIC 1 operating on the sending node 816.Such a failure may occur should NIC 1 be removed from the node, its NICdriver fail, the NIC itself fail, or the like. The failure may bedetected by NETFT via an event indication, such as a PnP event or thelike, and/or a heartbeat failure. In such a situation Path A istypically considered to have failed and NETFT will select an alternateend-to-end-operational pathway.

Failure 1020 indicates a failure of the network media coupling with NIC1of node 816. This failure may be due to a cable being disconnected fromNIC 1, from the cable becoming disconnected from some device of network1 202, from the device the cable is connected to on the network sidebeing powered down or failing, or the like. This type of failure mayalso be detected by NETFT via an event indication, such as a PnP eventor the like, and/or a heartbeat failure and an alternate pathwayselected.

Failure 1030 indicates a failure of some type within network 202resulting in data packets failing to reach destination node 966. In thisfailure case, sending node 816 may still be coupled to network 202 witha proper media sense indication, yet Path A has become disrupted furtherdown the network. Given such a failure. NETFT operating on sending node816 may not detect the failure via an event indication, such as a PnPevent or the like, if local indications show connectivity to the network202 as good, but may detect the failure via Path A heartbeat failure.

Failure 1022 of link 203 and failure 1012 of NIC 1 operating onreceiving node 966 tend to be similar to the corresponding failuresshown for node 816. But these failures, not being local to node 816 maynot be detected via event indications but may be detected via heartbeatfailure.

Any of these failures, and other failures, may be detected by NETFToperating on node 816 and result in it selecting an alternate end-to-endoperational pathway, such as Path 6 over network 2 282. In this example,as shown in FIG. 10, NETFT tunnels data down alternate path 1081 andover network 2 282 to receiving node 966. Should the failure conditionbe corrected and end-to-end operational status restored on Path A. NETFToperating on sending node 816 may detect the recovery and again make useof Path A. Further, any responses from node 966 back to node 816 may beforwarded or tunneled, depending on the operational status of Path A andPath B, in a similar fault-tolerant fashion by its NETFT.

FIG. 11 is a block diagram showing an example computing environment 1100in which the technology described above may be implemented. A suitablecomputing environment may be implemented with numerous general purposeor special purpose systems. Examples of well known systems may include,but are not limited to, personal computers (“PC”), hand-held or laptopdevices, microprocessor-based systems, multiprocessor systems, servers,workstations, consumer electronic devices, set-top boxes, and the like.

Computing environment 1100 generally includes a general-purposecomputing system in the form of a computing device 1101 coupled tovarious peripheral devices 1102, 1103, 1104 and the like. System 1100may couple to various input devices 1103, including keyboards andpointing devices, such as a mouse or trackball, via one or more I/Ointerfaces 1112. The components of computing device 1101 may include oneor more processors (including central processing units (“CPU”), graphicsprocessing units (“GPU”), microprocessors (“uP”), and the like) 1107,system memory 1109, and a system bus 1108 that typically couples thevarious components. Processor 1107 typically processes or executesvarious computer-executable instructions to control the operation ofcomputing device 1101 and to communicate with other electronic and/orcomputing devices, systems or environment (not shown) via variouscommunications connections such as a network connection 114 or the like.System bus 1108 represents any number of several types of busstructures, including a memory bus or memory controller, a peripheralbus, a serial bus, an accelerated graphics port, a processor or localbus using any of a variety of bus architectures, and the like.

System memory may include computer readable media in the form ofvolatile memory, such as random access memory (“RAM”), and/ornon-volatile memory, such as read only memory (“ROM”) or flash memory(“FLASH”). A basic input/output system (“BIOS”) may be stored innon-volatile or the like. System memory 1109 typically stores data,computer-executable instructions and/or program modules comprisingcomputer-executable instructions that are immediately accessible toand/or presently operated on by one or more of the processors 1107.

Mass storage devices 1104 and 1110 may be coupled to computing device1101 or incorporated into computing device 1101 via coupling to thesystem bus. Such mass storage devices 1104 and 1110 may include amagnetic disk drive which reads from and/or writes to a removable,non-volatile magnetic disk (e.g., a “floppy disk”) 1105, and/or anoptical disk drive that reads from and/or writes to a non-volatileoptical disk such as a CD ROM, DVD ROM 1106. Alternatively, a massstorage device, such as hard disk 1110, may include non-removablestorage medium. Other mass storage devices may include memory cards,memory sticks, tape storage devices, and the like.

Any number of computer programs, files, data structures, and the likemay be stored on the hard disk 1110, other storage devices 1104, 1105,1106 and system memory 1109 (typically limited by available space)including, by way of example, operating systems, application programs,data files, directory structures, and computer-executable instructions.

Output devices, such as display device 1102, may be coupled to computingdevice 1101 via an interface, such as video adapter 1111. Other types ofoutput devices may include printers, audio outputs, tactile devices orother sensory output mechanisms, or the like. Output devices may enablecomputing device 1101 to interact with human operators or other machinesor systems. A user may interface with computing environment 1100 via anynumber of different input devices 1103 such as a keyboard, mouse,joystick, game pad, data port, and the like. These and other inputdevices may be coupled to processor 1107 via input/output interfaces1112 which may be coupled to system bus 1108, and may be coupled byother interfaces and bus structures, such as a parallel port, game port,universal serial bus (“USB”), fire wire, infrared port, and the like.

Computing device 1101 may operate in a networked environment viacommunications connections to one or more remote computing devicesthrough one more local area networks (“LAN”), wide area networks(“WAN”), storage area networks (“SAN”), the Internet, radio links,optical links and the like. Computing device 1101 may be coupled to anetwork via network adapter 1113 or the like, or, alternatively, via amodem, digital subscriber line (“DSL”) link, integrated services digitalnetwork (“ISDN”) link, Internet link, wireless link, or the like.

Communications connection 1114, such as a network connection, typicallyprovides a coupling to communications media, such as a network.Communications media typically provide computer-readable andcomputer-executable instructions, data structures, files, programmodules and other data using a modulated data signal, such as a carrierwave or other transport mechanism. The term “modulated data signal”typically means a signal that has one or more of its characteristics setor changed in such a manner as to encode information in the signal. Byway of example, and not limitation, communications media may includewired media, such as a wired network or direct-wired connection or thelike, and wireless media, such as acoustic, radio frequency, infrared,or other wireless communications mechanisms.

Those skilled in the art will realize that storage devices utilized toprovide computer-readable and computer-executable instructions and datacan be distributed over a network. For example, a remote computer orstorage device may store computer-readable and computer-executableinstructions in the form of software applications and data. A localcomputer may access the remote computer or storage device via thenetwork and download part or all of a software application or data andmay execute any computer-executable instructions. Alternatively, thelocal computer may download pieces of the software or data as needed, ordistributively process the software by executing some of theinstructions at the local computer and some at remote computers and/ordevices.

Those skilled in the art will also realize that, by utilizingconventional techniques, all or portions of the software'scomputer-executable instructions may be carried out by a dedicatedelectronic circuit such as a digital signal processor (“DSP”),programmable logic array (“PLA”), discrete circuits, and the like. Theterm “electronic apparatus” may include computing devices or consumerelectronic devices comprising any software, firmware or the like, orelectronic devices or circuits comprising no software, firmware or thelike.

The term “firmware” typically refers to executable instructions, code ordata maintained in an electronic device such as a ROM. The term“software” generally refers to executable instructions, code, data,applications, programs, or the like maintained in or on any form ofcomputer-readable media. The term “computer-readable media” typicallyrefers to system memory, storage devices and their associated media,communications media, and the like.

1. A system comprising a computing device that includes a plurality ofprotocol drivers, a final protocol driver, and a fault-tolerant driverthat is configured for detecting a failure of any of a plurality ofpathways, and that is further configured for receiving data from any ofthe plurality of protocol drivers and for forwarding the received datavia the final protocol driver to a destination.
 2. The system of claim 1where the fault-tolerant driver is further configured for enablingprotocol reliability to be provided by the final protocol driver.
 3. Thesystem of claim 1 where the fault-tolerant driver is further configuredfor not degrading route-ability of a protocol supported by the finalprotocol driver.
 4. The system of claim 1 where the fault-tolerantdriver is further configured for mapping a virtual address used by thedestination to an address used by a source of the received data.
 5. Thesystem of claim 1 where the fault-tolerant driver comprises a tunneladapter configured for maintaining a socket and for routing data via thesocket between the final protocol driver and any of the plurality ofprotocol drivers.
 6. The system of claim 1 where the fault-tolerantdriver is further configured for mapping physical addresses to virtualaddresses.
 7. The system of claim 1 where the fault-tolerant driver isfurther configured for monitoring health of each of the plurality ofpathways.
 8. A method comprising: receiving data from any of a pluralityof protocol drivers by a fault-tolerant driver operating on a computingdevice that includes the plurality of protocol drivers, a final protocoldriver, and the fault-tolerant driver that is configured for detecting afailure of any of a plurality of pathways; and forwarding, by the faulttolerant driver, the received data via the final protocol driver to adestination.
 9. The method of claim 8 where the fault-tolerant driver isfurther configured for enabling protocol reliability to be provided bythe final protocol driver.
 10. The method of claim 8 where thefault-tolerant driver is further configured for not degradingroute-ability of a protocol supported by the final protocol driver. 11.The method of claim 8 where the fault-tolerant driver is furtherconfigured for mapping a virtual address used by the destination to anaddress used by a source of the received data.
 12. The method of claim 8where the fault-tolerant driver comprises a tunnel adapter configuredfor maintaining a socket and for routing data via the socket between thefinal protocol driver and any of the plurality of protocol drivers. 13.The method of claim 8 where the fault-tolerant driver is furtherconfigured for mapping physical addresses to virtual addresses.
 14. Themethod of claim 8 where the fault-tolerant driver is further configuredfor monitoring health of each of the plurality of pathways.
 15. At leastone computer storage device storing computer-executable instructionsthat, when executed by a computing device, cause the computing device toperform a method comprising: receiving data from any of a plurality ofprotocol drivers by a fault-tolerant driver configured for operating onthe computing device that includes the plurality of protocol drivers, afinal protocol driver, and the fault-tolerant driver that is configuredfor detecting a failure of any of a plurality of pathways; andforwarding, by the fault tolerant driver, the received data via thefinal protocol driver to a destination.
 16. The at least one computerstorage device of claim 15 where the fault-tolerant driver is furtherconfigured for enabling protocol reliability to be provided by the finalprotocol driver.
 17. The at least one computer storage device of claim15 where the fault-tolerant driver is further configured for notdegrading route-ability of a protocol supported by the final protocoldriver.
 18. The at least one computer storage device of claim 15 wherethe fault-tolerant driver is further configured for mapping a virtualaddress used by the destination to an address used by a source of thereceived data.
 19. The at least one computer storage device of claim 15where the fault-tolerant driver comprises a tunnel adapter configuredfor maintaining a socket and for routing data via the socket between thefinal protocol driver and any of the plurality of protocol drivers. 20.The at least one computer storage device of claim 15 where thefault-tolerant driver is further configured for mapping physicaladdresses to virtual addresses or for monitoring health of each of theplurality of pathways.